The development of application and system software for data processing systems has traditionally been a time-consuming and somewhat repetitive task, with software developers often having to write or rewrite code to perform well-known user interface and system functions in addition to writing the code utilized to implement the desired new functionality. Recently, object-oriented programming (OOP) has emerged as a dominant new programming paradigm that enables the rapid development and implementation of functionality while permitting the customization and reuse of objects.
The power of OOP as a software development philosophy is realized chiefly through object frameworks, which provide a collection of base object classes that can be selectively utilized by a system developer to create a software system, much like a hardware developer might construct a desktop computer from standard hardware components. Object frameworks are particularly advantageous when utilized within a distributed computing environment in which multiple, possibly heterogeneous, computer systems are interconnected to allow system hardware and software resources to be shared between computer systems. In order to permit programs written in multiple diverse languages to utilize object classes defined within a single object framework, it is necessary to develop a minimum level of object standardization, thereby enabling, at least to some degree, the interoperability of object-oriented software. One organization that is working to establish industry guidelines and object management specifications to provide a common object framework for application development is the Object Management Group (OMG). The specifications promulgated by OMG enable the reusability, portability, and interoperability of object-based software in heterogeneous distributed computing environments (HDCE). An example of a commercially available object framework that conforms to OMG specifications is the Distributed System Object Model (DSOM), which is described, for example, in the "SOM Objects Toolkit version 3.0 Programmer's Guide, Volume 1: SOM and DSOM", available from International Business Machines Corporation.
The Object Management Group (OMG) defines an industry standard for Life Cycle Services in "CORBAservices: Common Object Services Specification", OMG Document No. 95-3-31. Within the OMG Life Cycle Services standard, a number of object-oriented programming interfaces are defined in support of the creation and destruction of objects within a heterogeneous distributed computing environment (HDCE). Among the interfaces introduced within the OMG Life Cycle Services standard is the FactoryFinder interface, which provides a standard service that can be utilized by applications to locate a Factory object (i.e., an object that is used to create instances of other objects) within the heterogeneous distributed computing environment (HDCE).
The OMG FactoryFinder interface introduces an operation called find.sub.-- factories, which returns an Interface Definition Language (IDL) sequence of Factory objects that satisfy input criteria specified within a factory.sub.-- key input parameter. In heterogenous distributed data processing systems that contain hundreds or thousands of objects, of which many may satisfy a particular factory.sub.-- key, the number of Factory objects returned in the sequence can be large. Consequently, the user may desire to restrict the scope of the FactoryFinder find.sub.-- factory method to a specific set of servers in order to control which factory objects are returned.
Although controlling the behavior of the FactoryFinder method by restricting activities to a specific location scope is highly desirable, the OMG specifications do not define a standard interface which enables a user to specify a location scope. Although location scope may be encapsulated within a FactoryFinder object, each FactoryFinder object would have to have a unique implementation, and modifying the scope at runtime would not be a simple matter. Consequently, it would be desirable to provide an interface capable of defining a location scope, and more particularly, an interface compatible with the OMG FactoryFinder interface that may be used as the scope of FactoryFinder operations. It is also desirable to be able to associate a location object with a FactoryFinder object, or any number of FactoryFinder objects, in order to enforce a location scope for the behavior of the FactoryFinder object or objects.